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Background of the Invention 

Field of the Invention 

This invention relates to an integrated medical database system. More 
specifically, this invention relates to a compliance filter for a medical database in the 
emergency medical transportation industry. 

Description of the Related Technology 

Current documentation procedures in the medical transport industry are based on 
an inefficient paper and pencil technology. Important information is frequently 
collected on loose sheets of paper. In the environment of emergency medical transport, 
little time is available to neatly chart and document all pertinent and required 
information on a single document. Dispatch data, demographic data and clinical data 
are normally tracked as fragmented pieces of information that are later coalesced into a 



complete patient chart. In many cases, these data include the same information, thus 
forcing the input of redundant information. The resultant chart is therefore vulnerable 
to being incomplete and unreliable. In a medical setting, incomplete information can 
lead to disastrous clinical results. 

This same technology is used to support industry quality improvement and 
billing procedures and submit letters of transport justification. This paperwork is 
usually carried out well after the date the patient is encountered, prolonging account 
receivable times in many instances to the point of compromising and jeopardizing 
service compensation. Inventory stocking and tracking is similarly a victim of extended 
turnover times and is often incomplete and inaccurate. 

The fragmentation throughout the medical transport environment is also evident 
in the myriad of entities throughout the country practicing different standards of care 
and documentation. As is the case in other segments of the healthcare industry, even 
seemingly simple tasks of communicating among the various entities, as well as among 
sections of a single providing entity, is severely hampered by the lack of a common 
communication format. This is especially evident when certain aspects of the system 
(such as computerized clinical laboratory result displays) have been upgraded with a 
uniquely tailored computerized system, while the remaining functions are still 
performed in an archaic manner. While the upgraded system may be effective for one 
singular aspect, such as dispatching, lab reporting, or chart dictating, the remainder of 
the system does not improve its effectiveness due to the other archaic components. 

Current systems similarly depend on paper based systems that are labor and time 
intensive, and frequently suffer from human error, and forgetfulness. Compliance 
management is an absolute requirement in today's medical reimbursement environment, 
and there are significant financial penalties to not following a compliance management 
plan. What is desired is an electronic way of reducing the labor, time, and human 
error/forgetfulness. Furthermore, a capability where an adjustable percentage of clients 
are randomly and electronically audited and specific high-risk areas are identified for 
manual review would enhance such a medical system and are therefore also needed. An 
automated process is desired, such that before completion and transmission of data, the 
process would be initiated to assure data integrity, accuracy, and compliance with 
applicable reimbursement and regulatory standards. Such a process would identify 



discrepancies based on data collected from prior records and would allow immediate 
correction of inconsistent, inaccurate and non-compliant information. 

Summary of Certain Inventive Embodiments 
One aspect of the present invention is a computerized, integrated emergency 
medical transportation database system having a compliance audit component, the 
system comprising a medical emergency database configured to store at least clinical 
encounter information, patient demographic data and transport information; and a 
compliance audit component in communication with the medical emergency database, 
wherein the compliance audit component is configured to check to ensure that data in 
the medical emergency database for a current encounter is consistent with a high risk 
compliance area, and prompt for correction of the data where the data is not consistent. 

Another aspect of the invention is a method of performing a compliance audit 
for an integrated emergency medical transportation database system, the method 
comprising collecting at least clinical encounter information, patient demographic data 
and transport information into a medical emergency database; identifying one or more 
high risk compliance areas; applying a specific library of modifiable data rules to ensure 
that the collected data is consistent with the high risk compliance areas; and prompting 
for correction of the data where the data is not consistent. 

Yet another aspect of the invention is a computerized, integrated emergency 
medical transportation database system having a compliance filter, the system 
comprising a medical emergency database configured to store at least clinical encounter 
information, patient demographic data and transport information; and a compliance 
filter in communication with the medical emergency database, wherein the compliance 
filter is configured to use a specific library of modifiable data rules to ensure that data in 
the medical emergency database for a current encounter is consistent with a high risk 
compliance area, and prompt for correction of the data where the data is not consistent 
or compliant. 

Brief Description of the Drawings 
Figure 1 is a diagram illustrating the on-line computing environment of one 
embodiment of the medical database system, including a dispatch interface computer, 



server computer, backup computer, clinical and diagnosis interface computer, 
administrative interface computer and billing interface computer. 

Figure 2 is a block diagram illustrating one embodiment of the flow of data 
among a Dispatch module, a Clinical module, and a Billing module, in one embodiment 
of the medical database system. 

Figures 3a and 3b are a flowchart illustrating one embodiment of the 
Compliance Audit module process shown in Figure 2. 

Detailed Description of the Certain Inventive Embodiments 
The following detailed description presents a description of certain specific 

embodiments of the present invention. In this description, reference is made to the 

drawings wherein like parts are designated with like numerals throughout. 

For convenience, the discussion of the invention is organized into the following 

principal sections: Introduction, Hardware Overview, Data Flow Between Modules, 

Description of Software Module, and Conclusion. 

INTRODUCTION 

In certain embodiments, the present invention relates to an object oriented, 
interactive, international, client-server service for the medical transport industry. The 
service may integrate all aspects of patient record documentation into a single complete 
electronic chart. A server computer provides chart database information access to 
multiple transport providers simultaneously by securely transmitting, storing and 
maintaining standardized patient data, for instance, using guidelines set forth by the 
Scrambling Standards Organization. Individual transport-providing entities, such as 
helicopter and ambulance companies, obtain coded access to this server via phone lines 
with a modem equipped personal computer. Security is maintained by assigning each 
entity a unique code or identifier. Integrated Services Digital Network (ISDN) lines, 
Digital Satellite Systems (DSS), dedicated trunk lines (Tl, T3, etc.), cable modem, 
DSL, or digital wireless systems may also be used for communication. 

Each crew member involved in the patient's chart documentation, i.e. 
dispatcher, flight nurse, paramedic and physician, as well as administrator and collector, 
possess coded access to chart portions relevant to their responsibilities and level of care 



provided. The chart is then electronically generated from the compendium of the 
information entered in a standardized fashion and in accordance with minimum industry 
documentation requirements and the inventory of financial health care standards. The 
system provides complete and accurate chart documentation and maintains internal 
consistency between each separate module. Furthermore, any sentinel events are 
automatically referred to the appropriate, responsible party. A sentinel event is any 
action during the encounter that might require a further review. Examples of sentinel 
events are scene times exceeding 40 minutes, nonsensical or inconsistent data entry by 
an emergency transport crew member, supply shortages for equipment not utilized or 
repeated claim denials. 

Billing can be submitted electronically to the appropriate party in an appropriate 
format that reduces the accounts receivable times for each patient encounter. Letters of 
justification are automatically generated as well as follow up letters and utilization 
review reports. Inventory reports and lists of necessary base supplies and medicines are 
also electronically updated to appropriate supply centers and administrators. 
Customized and research reports can also be provided rapidly. 

Data security and an automatic backup are provided. Although the chart data is 
normally made the property of the respective transport service provider, the system can 
retain non-proprietary data to provide industry benchmarking, quality assurance 
analysis and clinical research opportunities. Such standardized data collection and 
documentation will furthermore enable the development of an Emergency Medical 
Services data library to assist in the justification and legislation of governmental 
preventive policies for public safety. 

HARDWARE OVERVIEW 
Figure 1 provides an overview of the computer hardware involved in one 
embodiment of the medical database system. In this embodiment, the medical database 
system 10 includes a server computer 12. The server computer 12 can be based on any 
well-known microprocessor such as those manufactured by Intel, Motorola, IBM or 
others. The server computer should be able to enable rapid simultaneous access to 
many users of the system. In one embodiment, the server computer 12 is an Intel 
Pentium III class computer having at least 256 Megabytes of RAM, a 10 gigabyte hard 



disk drive and a 500 MHz processing speed. Of course, many other standard or non- 
standard computers may support various embodiments of the medical database system 
10. 

The database application may be programmed in, for instance, ACIUS's 4th 
Dimension (4D) language and used in conjunction with the 4D Server and Client 
program. Also, another alternative computer environment is Microsoft Corporation's 
Visual Basic language with C++ middleware, and the BackOffice SQL Server program. 
It can therefore run in a standard Windows/Macintosh point-and-click office 
environment, and requires no additional, specialized software programming from the 
user. Of course, other standard or non-standard computer environments may support 
embodiments of the medical database system 10. 

As illustrated, the server computer can access a chart database 13. The chart 
database 13 stores the previously described electronic charts corresponding to patients 
that have utilized emergency medical transportation. The server computer can also 
access a statistical database 14 to store and extract statistical information from data 
entered during patient encounters. The collected statistics might include, for example, 
average scene and transport times, number of transport requests per demographic region 
and time of year, average number of advanced procedures performed by crew members 
and number of complications encountered. In addition, the database 14 can hold 
information relating to the average length of time to process claims by category and 
payment plan. 

The server computer can also be linked to a regional trauma database 15. The 
database 15 holds information relating to local trauma centers, emergency medical 
practice and other local trauma-related information. 

The dispatch module on the server computer 12 can be accessed via an interface 
to a dispatch computer 20, which might reside, for example, at the dispatch center that 
receives the initial call to deploy an emergency medical team. The dispatch computer 
20 can provide just a communications interface to the server computer 12 so that it acts 
as computer terminal, or it can contain a portion of the dispatch module. 

Based on the scene location and needs of the patient, the dispatch center might 
deploy a helicopter 24, airplane 25, ambulance 26, or other transportation mechanism. 
The dispatch computer 20 communicates with software for collecting information on 



the patient encounter and scheduling and deploying a crew to assist the injured patient. 
Within the medical database system 10, the helicopter 24, airplane 25 or ambulance 26 
would include a portable computer or computing device 30 (note that the portable 
computer 30 may be any electronic device that includes computing capability) that is 
used by the emergency medical team during the patient encounter. A wireless 
connection 32 can be made by the portable computer 30 to the server computer 12 to 
update the database 14 after any data has been entered. In other embodiments, other 
ways of communication with the server 12 can be used. The portable computer 30 can 
include clinical and diagnosis modules to assist the emergency medical team in treating 
the injured patient, or can act as a terminal to communicate with these modules on the 
server computer 12. As will be explained below, the clinical and diagnosis modules can 
help the emergency medical team determine the proper diagnosis and treatment of the 
patient. 

The medical database system 10 also includes a billing computer 36 in 
communication with the server computer 12. The billing computer 36 interfaces with 
the server computer 12 to run the billing module for tracking charges. The software 
billing module can be stored directly on the billing computer 36 or, alternatively, stored 
on the server 12 and accessed via the billing computer 36. The billing module is used to 
track charges, inventory, and medical equipment. In addition, it is used during the 
patient encounter for providing billing functions within the medical database system 10. 
The billing computer 36 communicates with a laser printer 38 to provide printed reports 
and bills to hospitals, patients and medical centers. 

An administration computer 40 interfaces with the server computer 12 to 
provide run administrative reports. These reports might relate to the statistical 
information contained in the statistical database 14. In addition, the administration 
computer 40 might run reports that relate to payroll, inventory, flight training or many 
other administrative issues. 

It should be noted that the dispatch interface computer 20, portable computer 30, 
billing computer 36 and administration computer 40 can communicate with the server 
computer 12 through a variety of mechanisms, as shown by connection paths 32 and 33. 
For example, a wireless LAN or cellular network may connect each computer with one 
another. In another embodiment, dedicated or dial-up phone lines can be used to 



communicate between the different computers. Communication mechanisms may 
include networks such as the Internet and may include virtual private networks (VPNs). 

DATA FLOW BETWEEN MODULES 

Referring now to Figure 2, a block diagram of one embodiment of the data flow 
between the various modules within the medical database system is illustrated. Figure 2 
illustrates the flow of data between a dispatch and demographic module 100 (hereafter 
referred to as the dispatch module), a clinical module 105 and a billing module 110. 
The dispatch module 100 includes a scheduling submodule 112, a standby submodule 
114, a transfer submodule 116 and a flight submodule 118. These various submodules 
process information received into the overall dispatch module 100. For example, crew 
information 120 is processed within the schedule submodule 112. In addition, scene 
information 122 is processed within the standby submodule 114. 

Patient demographics and patient lab information 124 is processed within the 
transfer submodule 116. Flight tracking and other transportation information 126 is 
processed within the flight submodule 118. Once the various submodules within the 
dispatch module 100 have processed their respective information, a set of patient 
demographic information 130 and flight information 135 is made available to the 
remaining modules. For example, some of the patient demographic information 130 is 
imported into the clinical module 105. 

In addition, many other pieces of data are placed within the clinical module 105. 
For example, the general assessment 140 of the patient that is taken by the emergency 
medical team is imported into the clinical module for further processing. In addition, 
other incident information 142 such as the type of incident (car accident, motorcycle 
accident, etc.) is sent to the clinical module 105. Prior treatment information 144 
obtained from a physical exam of the patient or other information is also sent to the 
clinical module 105. 

The prior treatment information might be important in determining whether the 
patient had already been treated for similar injuries thereby affecting the clinical 
diagnosis. Information collected from the physical exam 146 at the scene is also sent to 
the clinical module 105. In addition, any diagnosis 148 from the attending emergency 
medical team can be sent to the clinical module 105. It should be noted, as discussed 



below, that the medical database system 10 may also provide a diagnosis based on the 
physical exam information 146 and other information within the clinical module 105. 
This will be explained in more detail below. 

Information relating to the treatment 150 of the patient is also sent to the clinical 
module 105. The medical database system 10 also includes a quality assurance 
database 152 which allows the emergency medical team to make suggestions or other 
comments that may be useful in additional treatments or incidents. For example, if the 
emergency medical team notes that a particular series of exam results has led to a 
unique diagnosis, this information can be input into the clinical module 105. Thus, the 
next time these same physical exam results are seen in a patient, the new diagnosis can 
be suggested to the emergency medical team. 

Once the clinical module 105 has received its necessary information, data is 
output to a compliance audit module 169 and then further to the billing module 110. 
For example, a description of the diagnosis 160, a treatment description 162 or ICD-9 
codes 165 can be sent from the clinical module 105 to the compliance audit module 

169. As is well known, ICD-9 codes are a set of unique codes referring to most well- 
known medical procedures. These codes are used throughout the insurance industry to 
obtain payment for various medical procedures. In addition to the data from the clinical 
module 105, patient data 168 can be obtained from the patient demographic information 
130. The patient data and demographic information 168 along with the flight 
information 135 are also processed by the compliance audit module 169. The 
compliance audit module 169 will be described in conjunction with Figure 3 below. 
The output of the compliance audit module 169 can be fed into the billing module 110. 
This information is then used within the billing module 1 10 to generate reports and bills 

170. As is to be expected, these reports and bills are sent to the various insurance 
companies and insurance providers. Thus, the medical database system 10 is an 
integrated system for providing many services within the medical industry. Further 
descriptions of the software modules are provided in Applicant's U.S. Patent No. 
6,1 17,073, which is hereby incorporated by reference. 



DESCRIPTION OF SOFTWARE MODULE 
The Compliance Audit Module 

Referring now to Figures 3 a and 3b, a flowchart illustrating one embodiment of 
the compliance audit module process 169 (Figure 2) is described. The compliance audit 
module 169 may be configured for use as a compliance filter. In one embodiment, an 
adjustable percentage of clients are randomly and electronically audited and specific 
high-risk areas are identified for manual review. In another embodiment, before 
completion and transmission of data between modules and/or computers, the automated 
compliance audit 169 is initiated to assure data integrity, accuracy, and compliance with 
applicable reimbursement and regulatory standards. The compliance audit identifies 
discrepancies based on data collected from prior records and allows immediate 
correction of inconsistent, inaccurate and non-compliant information. 

As described above, patient and demographic data and transport information is 
collected at the dispatch and demographic module 100. A diagnosis, with 
corresponding ICD-9 codes, and a treatment are developed at the clinical module 105. 
The diagnosis description 160, the treatment description 162, the ICD-9 code(s) 165, 
the patient data 168, and the flight information 135 are forwarded to the compliance 
audit module process 169. 

At decision state 1050, the received information 160, 162, 165, 168 and/or 135 
is checked for new data. If the data is new, the compliance audit module process 169 
proceeds to state 1051 where it is amended into the record, such as into the chart 
database 13. A further determination is then made at decision state 1050 for new data. 
If there is no new data, process 169 advances to state 1052 where a payer requirements 
library of modifiable data rules is applied to the data. At state 1052, an audit is 
performed to determine if the data is complete and consistent with payer compliance 
requirements. The data is compared to the library of modifiable data rules that correlate 
and filter the data to identify high risk areas. Process 169 proceeds to a decision state 
1054 where the results of the audit (at state 1052) are checked to determine if the data is 
complete and consistent with payer compliance requirements. If the data is not 
complete or consistent, process 169 moves to state 1053 for amendment and 
reconsideration of the data, and then moves back to state 1052 to apply the library of 
modifiable rules again. 
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If the data is complete and consistent, process 169 advances to state 1055 where 
a high risk area library of modifiable data rules is applied to the data. Process 169 then 
moves to a decision state 1056 to determine whether the data is consistent with 
identified high risk compliance areas. A high-risk compliance area is a transport that 
meets specific criteria that are identified as carrying a risk for reimbursement fraud or 
abuse. An example of a high risk compliance area is for a two patient transport where 
the second patient is not medically necessary. An example of when the data may not be 
consistent is when the data may describe a stable patient with no injuries, but the crew 
may indicate that it is medically necessary. In one embodiment, the data is screened 
based on rules (at state 1055) for data points that identify the record as a high-risk 
compliance area. As an example, the dispatch and clinical data is screened and it is 
determined that the loaded mileage is less than ten miles and there are no extenuating 
circumstances documented that make this trip distance a justifiable transport by air. 
Medicare typically considers a transport of this distance as not medically necessary by 
air and will pay at ground rates. An exemplary rule can be as follows: 

- Does loaded mileage data indicate transport distance less than 10 loaded miles? 
YES 

- Are acceptable extenuating circumstances documented? 
NO 

- If answer above is No, then place display flight data in queue for manual 
review. 

The process 169 identifies discrepancies based on data collected from prior 
records and allows immediately correction of inconsistent, inaccurate and non- 
compliant information. Thus, if it is determined at the decision state 1056 that the data 
is consistent with identified high risk compliance areas, process 169 moves to state 
1058 where a warning and flag are set, in one embodiment, to indicate to the user that a 
manual review in either a focused or random audit should be performed. A warning is 
presented if the record indicates that additional user input is required to address 
identified compliance risk areas. The crew member completing the record is 
prompted/suggested to document their steps to minimize compliance risks at state 1060. 
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For example, a circumstance that may provoke going to state 1058 is when new 
demographic data is acquired causing the record to be amended. At state 1060, there 
would be user input responding to the warning indicating that data would be entered. 
Alternatively, the user would detail what steps they took to acquire data so that others 
would not duplicate their work. It should be realized that the determination of whether 
the data is consistent with high risk compliance areas (at decision state 1056) includes a 
random sampling mechanism where random patient encounters that are within a high 
risk compliance group are selected for manual audit. At the completion of state 1060, 
process 169 moves back to state 1055 to apply the library of modifiable rules again. 
Thus, amended data from 1060 is tracked, reviewed, and formatted into the relevant 
data rules library. 

If the data is consistent with identified high risk compliance areas, as determined 
at decision state 1056, process 169 then moves to state 1061 where a legislative 
requirements library of modifiable data rules is applied to the data. Process 169 
proceeds to a decision state 1062 where the results are checked of screening the data 
using the specific data rules library (at state 1061) to determine whether the data is 
consistent with legislative requirements. At decision state 1062, the legislative 
requirements may relate to, for example, the transport of a patient to a facility that is not 
the closest capable facility. Other legislative requirements may relate to the personnel 
configurations required for patient transport, procedure practices or types of necessary 
documentation. For example, it may be required that at least one doctor, one nurse and 
one emergency medical technician (EMT) be sent on every call. If the data is not 
consistent with legislative requirements, as determined at decision state 1062, process 
169 advances to state 1064 where the crew is warned and asked to amend specific 
missing data to meet legislative requirements. The user input responding to the warning 
is received at state 1066. At the completion of state 1066, process 169 then moves back 
to state 1061 to apply the library of modifiable rules again. 

If the data is consistent with legislative requirements, as determined at decision 
state 1062, process 169 proceeds through an off-page connector A to state 1068 (on 
Figure 3b) where a reimbursement standards library of modifiable data rules is applied 
to the data. Process 169 then advances to a decision state 1070 where the results are 
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checked of the rules screening (at state 1068) to determine whether the data is consistent 
with reimbursement standards. An exemplary rule is as follows: 

- Is transport data entered consistent with the rules library for reimbursement 
standards? 

-If answer is NO 

- Display data that is not consistent and request adjudication / correction 

- Is new data consistent? if YES, move to next step 

- If NO, then place display transport in queue for manual review. 

- Present results of manual review for possible modification to data rules 
library. 

The rules can be stored in rule libraries that are designed to be highly flexible to change 
as dictated by reimbursement, compliance, and regulatory changes. 

If the data is not consistent with reimbursement standards, as determined at 
decision state 1070, process 169 advances to state 1072 where the crew is warned and 
asked to amend specific missing data to meet the reimbursement standards. The user 
input responding to the warning is received at state 1074. At the completion of state 
1074, process 169 then moves back to state 1068 to apply the library of modifiable rules 
again. Thus, the user input is tracked, reviewed, and formatted into new data rules as 
applicable. 

If the data is consistent with the reimbursement standards, as determined at 
decision state 1070, process 169 advances to state 1075 where a regulatory standards 
library of modifiable data rules is applied to the data. Process 169 then advances to a 
decision state 1076. At decision state 1076, the results of screening the data to 
determine whether the data is consistent with regulatory standards (at state 1075) are 
checked. If the data is not consistent with regulatory standards, as determined at 
decision state 1076, process 169 advances to state 1078 where the crew is warned and 
asked to amend specific missing data to meet the regulatory standards. The user input 
responding to the warning is received at state 1080. At the completion of state 1080, 
process 169 then moves back to state 1075 to apply the library of modifiable rules 
again. Thus, the user input is tracked, reviewed, and formatted into new data rules as 
applicable. In one embodiment, the acquired data may be screened against 
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Consolidated Omnibus Reconciliation Act (COBRA) or Omnibus Reconciliation Act 
(OBRA) regulatory standards. This screening prevents the system from submitting a 
claim that does not satisfy these regulatory requirements. 

For example, if a patient is transported from another hospital, the process 169 
may search for the data point indicating that a signed Certificate of Medical Necessity 
accompanied the patient. If the Certificate of Medical Necessity data point is not found 
in the system, it may send a warning that in order for the accident costs to be 
reimbursed, the Certificate of Medical Necessity needs to be entered. Process 169 thus 
searches for compliance with the COBRA or OBRA rules, and the modifiable 
regulatory rules library and, if compliance is not found, notifies the user that more data 
is required. In another example, the patient might be left at the scene of an accident. If 
this occurs, the process 169 looks for appropriate documentation (based on the 
modifiable data rules library) of patient release against medical advice. If this data is 
not present, it flags this error and reports that such data is required for compliance with 
the COBRA and OBRA rules. 

If the data is consistent with the regulatory standards, as determined at decision 
state 1076, process 169 completes and then the electronic chart record is released for 
billing review and bill preparation at the billing module 110. 

CONCLUSION 

Specific blocks, sections, devices, functions and modules may have been set forth. 
However, a skilled technologist will realize that there are many ways to partition the 
system of the present invention, and that there are many parts, components, modules or 
functions that may be substituted for those listed above. 

As should be appreciated by a skilled technologist, the processes that are 
undergone by the above described software may be arbitrarily redistributed to other 
modules, or combined together in a single module, or made available in a shareable 
dynamic link library. The software may be written in any programming language such 
as C, C++, BASIC or Visual BASIC, Pascal, Java, and FORTRAN and executed under 
a well-known operating system, such as variants of Windows, Macintosh, Unix, Linux, 
Vx Works, or other operating system. C, C++, BASIC or Visual BASIC, Pascal, Java, 
and FORTRAN are industry standard programming languages for which many 
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commercial compilers can be used to create executable code. A database programming 
language such as ACIUS's 4th Dimension (4D) language used in conjunction with the 
4D Server and Client program may also be used. 

While the invention has been described in connection with specific embodiments 
thereof, it will be understood that it is capable of further modification, and this application 
is intended to cover any variations, uses, or adaptations of the invention following, in 
general, the principles of the invention and including such departures from the present 
invention as would be understood to those in the art as equivalent and the scope and 
context of the present invention is to be interpreted as including such equivalents and 
construed in accordance with the claims appended hereto. 
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